Next things in zcash
Verifiabilityのボトルネックになっているnullifier accumulatorを取り除いていきたい方針。
Design a windowed or rolling epoch system to limit the size of the commitment tree and nullifier set
The second iteration of the counterfeit detection turnstile
proposal to charge higher fees for spending old UTXOs
scale zcash by moving block validation inside a snark
Bonsai: private payments on a succinct (or partially succinct) blockchain
Shielded support for custodian use cases
1st milestoneがmulti-sig or threshold sig
For multisig only, I don't think this is likely to require an effort of 10 person-months (problems with "person-month" as a measure notwithstanding). There's a large sunk cost associated with the development and analysis of MuSig (by people outside ZcashCo) and the identification of MuSig adapted to RedDSA as being a possible solution for n-of-n shielded multisig in Zcash, but sunk costs shouldn't be counted.
Here are my estimates for n-of-n multisig:
remaining specification effort: 1 person for 0.5 months
remaining analysis effort within ZcashCo: 1 person for 1 month
consensus implementation effort (zcashd): none; no consensus change required
non-consensus implementation effort (zcashd): 1 person for 1.5 months
support implementation effort (ecosystem): high
(None of these times can be reduced significantly by adding more people.)
I can't estimate (n-1)-of-n multisig or whether that is feasible in the Blossom timeframe yet, and I can't estimate the cost if MultiRedDSA doesn't meet the requirements (not all of which are written down yet).
Plus there's the "fun" option of implementing set non-membership checks in the circuit. If we can figure out how to prove that efficiently, then verification state reduces to roughly a Merkle tree.
Bonsai
mutableなaccountsのtree間における状態遷移の検証をCodaの技術ベースで行う。
privacyな特性を持ちながら送るアカウントと受け取るアカウントの両方の状態を知る必要がある。
utxoベースでzcashのcommitment/nullifierスキームのまま適用しようとするとそれぞれのupdateを証明する必要があり、nullifierアキュムレータのnon-membership proofが必要になり、効率性的にも厳しい。
なので、それぞれのアカウントはspending keypairとreceiving keypairを持っており、そのアドレスは両方の公開鍵から成っている。
アカウント（Address, positions in the account tree, State) から成る。
アカウントAからアカウントBにTransferするときは、
両者のAccountのタプル情報が必要
AのSpending private keyが必要
AccountBが新規アカウントあるいは、Bのreceiving private keyが必要
受け手のアドレスとともに新規アカウントに送る。（ addressだけでおk）
受け手にoffchainでprivateにアカウントのstateを送る。